【论文】HPC数据存储系统中Burst Buffer超额分配方案的设计与实施
摘要
Burst Buffer在超级计算机中心得到广泛应用，主要用于弥补计算能力与高性能I/O系统之间的性能鸿沟。其核心作用在于暂时缓解突发的I/O需求，减轻对并行文件系统（PFS）的访问压力。然而，高性能计算机（HPC）系统上的作业资源管理器更倾向于采用专用的Burst Buffer分配方式，这导致Burst Buffer资源未能得到充分有效利用。
为了提高这些宝贵资源的使用效率，我们深入研究了Burst Buffer上的I/O模式，并提出了Burst Buffer超额分配策略。这一策略允许每个作业仅在其I/O阶段访问Burst Buffer，从而实现了作业的相互重叠使用。此外，我们还研发了全新的I/O拥塞感知调度程序和透明数据管理系统，这些系统能够在Burst Buffer和PFS之间无缝协作。
通过采用适应性持久性内存技术，我们的方法不仅降低了数据管理系统的内存开销，还增强了数据的持久性。应用这一方法，不仅能够显著提升Burst Buffer的利用率，还能使HPC应用程序充分利用Burst Buffer的强大硬件功能，实现卓越的I/O性能。
实验数据表明，与其他先进的调度程序相比，我们的BBOS系统能够将Burst Buffer的利用率提升高达120%。即便在高I/O负载下，也能保证更稳定、更高效的检查点性能。此外，我们的方法还能将重启请求的命中率提升至96.4%，并在Burst Buffer上实现高达210%的重启吞吐量增长。
I. 引言
随着计算能力达到每秒千万亿次浮点运算（petaflop）级别，HPC系统中部署了大量系统组件，导致整体系统故障率上升[1][2][3]。为确保故障安全性，HPC应用程序普遍采用检查点（checkpoint）和重启（restart）策略作为主要的容错机制。然而，这些机制会产生大量的突发I/O，占据整个HPC系统总I/O流量的75%至80%[2][4]。由于PFS主要由廉价的机械硬盘或低端闪存固态硬盘构成，处理这些由检查点和重启操作产生的大量I/O访问变得异常困难，进而影响了整体的I/O性能。
为了缓解PFS的压力并提升I/O性能，高端闪存固态硬盘（如3D XPoint SSD和NVMe SSD）组成的Burst Buffer被引入，作为计算节点与PFS之间的新存储层[5][6]。由于Burst Buffer与PFS在性能上存在显著差异，HPC用户往往希望为其提交的作业的整个生命周期分配专用的Burst Buffer资源。
然而，当前的专用Burst Buffer分配机制却导致资源严重浪费。一方面，HPC用户常常请求过多的Burst Buffer资源，例如高达6倍之多[3]。根据NERSC（National Energy Research Scientic Computing Center）Cori超级计算机系统的真实日志数据，仅有5%的整体Burst Buffer资源被实际使用。这主要是因为用户希望防止可能的I/O错误、提高I/O性能，并避免Burst Buffer与PFS之间复杂的数据移动。另一方面，由于HPC应用程序仅在I/O阶段使用Burst Buffer，其余时间资源都处于闲置状态。尽管检查点占据了HPC系统的大部分I/O流量，但两次连续检查点操作之间往往存在较长的间隔，导致大部分时间内分配的Burst Buffer资源被浪费。
针对这一问题，本文提出了一种高效的HPC存储管理方法——Burst Buffer超额分配方法（Burst Buffer Over-Subscription），简称BBOS。为支持这一方法，我们在调度I/O作业时，透明地管理Burst Buffer与PFS之间的数据移动。BBOS的核心思想在于充分利用检查点和重启操作占据HPC存储系统大部分I/O流量的特点。由于这些机制具有特定的I/O特性，使用传统的数据管理方法可能会导致性能下降。因此，我们引入了一种新的数据放置调度策略，专门针对检查点和重启操作的特性，优化Burst Buffer与PFS之间的数据流动。
为了验证BBOS框架在提高Burst Buffer利用率和检查点/重启性能方面的效果，我们将其与Cray DataWarp（当前代表性的HPC调度程序，采用专用Burst Buffer分配方法）和Harmonia（考虑Burst Buffer超额分配方法的基于Burst Buffer的动态I/O调度程序）进行了比较评估。结果显示，与使用DataWarp相比，BBOS框架可将Burst Buffer利用率提高高达120%，同时保持稳定的检查点性能。此外，通过充分利用检查点和重启操作的特性，我们的方法还可在Burst Buffer上将重启性能提升高达96.4%。
在之前的工作中[9]，我们为了解决大多数HPC系统中Burst Buffer资源未被充分利用的问题，成功实现了Burst Buffer超额分配框架。这一BBOS框架由I/O引擎、数据管理引擎以及内存键值存储组成，旨在高效处理HPC应用程序的检查点和重启操作。在BBOS框架的基础上，我们进一步通过引入持久性内存来扩展原有功能。具体来说，我们使用了NVDIMM，在Redis内存键值数据库上实现了框架的改进版本。这样做的好处在于，内存容量可以低成本地增加，并且即使在断电的情况下也能保证数据的持久性。我们测试了NVDIMM上存储大部分数据的BBOS应用，结果显示并未出现I/O性能下降的情况。
此外，我们还对应用了NVDIMM的BBOS设计进行了深入评估，展示了实现细节，并解释了BBOS框架在Burst Buffer中的检查点、重启和降级操作的工作流程。
我们的主要贡献包括：
采用超额分配的方法，实现了对Burst Buffer资源的高效利用。
深入分析了HPC应用程序的检查点和重启操作的特性，发现现有数据管理方法未能充分考虑到这些特性，导致I/O性能不佳。
提出了新颖的HPC数据管理方法——BBOS，不仅提高了Burst Buffer的利用率，还保证了稳定且高效的检查点和重启性能。BBOS能够调度I/O作业，自适应地调整降级阈值和I/O带宽，并优化Burst Buffer与PFS之间的数据放置策略。
通过在GlusterFS上添加多个模块，实现了BBOS的原型系统。同时，利用持久性内存降低了DRAM的开销，并在应用BBOS框架到Burst Buffer时增强了数据的持久性。
II. 背景和动机
A. 未充分利用的Burst Buffer
Burst Buffer位于计算节点与存储系统之间，作为中间层，用于缓解HPC系统中的突发I/O情况[10]，[11]。每个Burst Buffer节点都集成了高成本的硬件资源，如高速存储介质和高速网络。目前，多数超级计算机，如NERSC的Cori超级计算机[12]和ORNL（Oak Ridge National Laboratory）的Summit超级计算机，均采用专用的Burst Buffer分配方法来分配资源。用户在申请时指定所需容量或指定用于应用程序的节点，随后，HPC调度程序[13]，[14]会在整个应用程序运行期间为其提供所需空间。
然而，这种专用分配方式常常导致Burst Buffer资源利用不足。原因在于，HPC用户往往会预留比实际需求更大的Burst Buffer空间。这是因为，当Burst Buffer容量不足以满足I/O需求时，应用程序作业会因I/O错误而终止。为避免此类情况，超级计算机供应商建议用户预留更多Burst Buffer容量[3]。用户不仅因担心作业失败而预留过多容量，还期望以此获得更高性能。此外，多层次HPC存储系统（包括计算节点的本地存储、Burst Buffer和PFS）中的复杂数据管理也是用户预留过多容量的原因。由于当前超级计算机分别管理Burst Buffer和PFS，用户面临冗余和复杂的管理挑战。例如，若用户仅使用有限的Burst Buffer容量写入检查点，他们需手动在每个检查点阶段结束后将数据从Burst Buffer复制到PFS，以释放Burst Buffer空间供下一阶段使用[15]。
另外，不考虑检查点和重启操作的特性，直接执行Burst Buffer保留过程，也加剧了资源利用不足的问题。HPC应用程序通过周期性重复计算阶段和I/O阶段，在固定时间间隔内执行检查点操作[16]，[17]，[18]，称为检查点周期。然而，检查点周期持续时间差异大，从几十分钟到几十小时不等，导致昂贵的Burst Buffer资源在计算阶段长时间闲置。此外，为确保数据安全，Burst Buffer需至少保留两倍于检查点数据容量的空间，因为新检查点文件完全写入前，旧文件需保持保留状态。若用户决定在Burst Buffer中存储多个版本的检查点文件以提高数据持久性，则将进一步加剧Burst Buffer的利用不足问题，因为除最新版本外，其他旧版本文件很少被访问。
基于专用Burst Buffer分配方法导致的上述问题，我们提出了基于超额分配的HPC存储管理方法。
B. 检查点和重启操作的特性
与普通应用程序相比，HPC应用程序具备独特的检查点与重启特性。为了成功在HPC存储系统上实施超额分配的Burst Buffer方法，我们需要构思一种全新的数据管理方案，并充分考虑以下五个与检查点和重启紧密相关的特点。
首先，大部分HPC应用程序专注于解决计算密集型问题，并在特定周期内执行检查点操作。经观察，我们发现在一个特定的周期内写入Burst Buffer的检查点数据总量（我们称之为每周期写入数据量DWPP）相当稳定。因此，我们可以利用以往运行的DWPP值来预测作业未来的DWPP。
其次，每个应用程序都有其特定的检查点周期和检查点操作之间的时间间隔。这意味着每个应用程序仅在特定的检查点周期内访问Burst Buffer。例如，检查点周期较短的HPC应用程序会比那些周期较长的应用程序更频繁地访问Burst Buffer。
第三，为了提高数据的耐久性，HPC应用程序通常保留多个版本的检查点文件。尽管重启过程仅需最新版本的检查点文件，但许多HPC用户选择保留旧版本文件而不删除。由于用户在运行作业时对数据可靠性的需求各异，因此每个应用程序作业会保留不同数量的检查点版本。
第四，HPC应用程序的故障率各不相同。这些故障可能由多种组件引起，包括处理器、磁盘、内存、电源、网络、冷却系统以及它们之间的物理连接。由于这些组件众多，故障发生较为频繁。先前的研究表明，单个节点的平均故障间隔时间（MTBF）可达数千小时，但大型集群（包含数百个节点）的MTBF可能仅为数十小时。简而言之，随着HPC应用程序使用的节点数量增加，故障率也相应上升。
最后，HPC应用程序的检查点文件之间不存在数据局部性。这意味着在检查点文件之间既没有时间局部性，也没有空间局部性。因为只有在发生故障时才会访问检查点文件，所以即使某些检查点文件被存储在相邻位置，除非发生故障，否则这些文件不会被访问。
C. 问题分析
与专用Burst Buffer分配方法相比，超额分配方法给予应用程序的空间超过了实际容量。为确保这一策略有效，应用程序仅能在I/O阶段访问Burst Buffer。而在计算阶段，则需将数据从Burst Buffer迁移至PFS，以便其他I/O阶段的应用程序能使用。因此，我们亟需一种高效的数据管理方法，确保在Burst Buffer与PFS间顺畅流转数据，且不影响整体性能。尽管过去的研究在多层系统中提出了一些高效的数据管理策略[3]，[8]，[25]，[26]，但这些方法并不适用于HPC存储系统，因为检查点操作占据了大部分的I/O流量。原因如下：
先前的工作采用了静态降级阈值，却未考虑在存储层间移动的数据量。根据先前的方法，只有当Burst Buffer空闲时，才会进行降级操作。然而，当Burst Buffer的使用总量达到预设阈值时，降级操作必须与检查点操作同步进行。由于超额分配方法使得更多作业能够访问Burst Buffer，因此Burst Buffer很快就会被检查点数据填满。结果便是，降级操作会频繁地打断检查点操作。
图1展示了当降级阈值设为Burst Buffer总容量的90%时，不同DWPP（每周期写入数据量）对检查点性能的影响。在图中，S代表Burst Buffer的总容量，而1.3S、1.6S和1.9S分别代表写入了1.3倍、1.6倍和1.9倍于Burst Buffer大小的检查点数据。图中的每个点代表了在Burst Buffer上运行的应用程序作业随时间的变化情况。我们主要考虑了总检查点文件大小超过Burst Buffer大小（即DWPP>S）的超额分配场景，这样可以提高Burst Buffer的利用率。当只有少数作业使用Burst Buffer时（即DWPP < S），每个作业都能获得较高的I/O性能，但Burst Buffer的利用率会相对较低。
当DWPP达到1.3S时，作业性能在1000秒后略有下降，因为并发运行的作业数量增加。然而，当DWPP增至1.6S时，检查点I/O操作中间，Burst Buffer被完全占用，性能随时间逐渐下降。在1.9S的情况下，几乎有一半的作业性能比其他作业低四倍，因为检查点操作必须暂停并等待降级操作释放Burst Buffer空间。
先前工作的另一个不足是未考虑检查点操作的到达模式在数据管理策略中的重要性。例如，HPC作业使用不同周期发出检查点操作。当到达时间间隔较长时，检查点操作之间会有足够的Burst Buffer空闲时间。此时，文件可以被降级到PFS，为下一个I/O作业在Burst Buffer中腾出空间。然而，如果检查点操作的到达时间间隔很短，Burst Buffer的空闲时间就会不足，导致在下一个检查点操作之前完成数据迁移变得困难。这不可避免地会导致Burst Buffer容量的枯竭。
图2显示了在相同的DWPP下，检查点性能与I/O作业的拥塞率密切相关。低、中和高三种拥塞模式分别代表了I/O作业到达的繁忙程度，而这些作业被允许使用1.9倍于Burst Buffer大小的空间。从图中可以看出，在低拥塞率的情况下，作业能够获得高性能，因为在I/O操作之间有足够的空闲时间。相反，当中等和高拥塞情况发生时，一些I/O作业会经历低检查点性能。
简单地采用数据驱逐策略算法，如FIFO（先进先出）、LRU（最近最少使用）和LFU（最不经常使用），会导致Burst Buffer利用率低下。HPC应用程序具有特定的检查点周期，并保留不同数量的检查点文件用于数据恢复。使用FIFO算法时，具有长检查点周期的应用程序的最新检查点文件可能被视为冷数据，而具有短周期的旧版本检查点文件则被视为热数据。这导致具有长检查点周期的应用程序面临低恢复性能，进而降低了Burst Buffer的效率。此外，由于检查点文件缺乏数据局部性和空间局部性，因此LRU或其他热感知算法并不适用于数据驱逐策略。为了更有效地选择需要驱逐的检查点文件，我们必须考虑故障率。若不考虑故障率，可能会错误地将具有较高故障率的检查点文件作为冷数据，而不是选择具有较低故障率的检查点文件。
III. Burst Buffer中的数据管理
如果没有充分考虑到检查点和重启操作的特性，应用程序的性能可能会遭受严重影响。在本文中，我们为Burst Buffer设置了降级阈值，并提前对检查点和降级操作的速度进行了调整，旨在防止性能下降。此外，我们还开发出一种新颖的数据放置策略，用以管理Burst Buffer和PFS之间的数据迁移。
A. 自适应降级调整
为了在使用超额分配方法时释放Burst Buffer中的空间，我们经过慎重考虑，设定了一个降级阈值，该阈值综合考虑了DWPP（每周期写入数据量）和I/O作业的拥塞率。这些数据均来源于应用程序作业的日志历史。如图1所示，DWPP直接影响了每个周期内需要降级的数据量。当DWPP较大时，意味着有大量的I/O数据需要写入Burst Buffer，此时就需要及时降级数据，以释放Burst Buffer中的空间。同时，Burst Buffer的填充速度也受I/O作业拥塞率的影响，如图2所示。
在设定降级阈值时，我们还需考虑检查点和降级操作的吞吐量。当两者同时执行时，在Burst Buffer的I/O能力范围内，写入带宽和读取带宽之间存在一种反向关系。因此，最小降级吞吐量（Brmin，即Burst Buffer提供的最小读取吞吐量）由最大检查点吞吐量（Bwmax，即Burst Buffer提供的最大写入吞吐量）决定；而最小检查点吞吐量（Bwmin，即Burst Buffer提供的最小写入吞吐量）则由最大降级吞吐量（Brmax，即Burst Buffer提供的最大读取吞吐量）决定，具体如方程（1）所示。
值得注意的是，Burst Buffer提供的读取吞吐量会受到PFS（持久文件系统）提供的写入吞吐量的影响。此外，m和b的值取决于设备的I/O能力。为了避免Burst Buffer空间耗尽时可能出现的最坏情况，我们的策略是在已用Burst Buffer空间达到降级阈值后，将检查点吞吐量从Bwmax调整为Bwmin，同时将降级吞吐量从Brmin调整为Brmax。
展示了在不同DWPP下的聚合Burst Buffer写入带宽。我们的总体目标是在处理检查点周期内写入Burst Buffer的DWPP数据量的同时，保持尽可能高的最大检查点带宽。假设S为Burst Buffer的容量，我们将周期内迄今为止写入的数据量称为DWSF。在一个周期内，若在Bwmax下执行检查点操作且没有降级发生，所需时间为tc；而执行C量数据降级所需的时间为td，td由tdd和tds组成：tdd表示降级吞吐量从Brmin逐渐增加到Brmax所需的时间，而tds表示降级吞吐量固定为Brmax且不改变的时间。为确定降级阈值，我们将降级操作的I/O模式分为三类进行考量。
模式1：仅在Burst Buffer空闲时执行降级
当DWPP小于Burst Buffer容量S的1.0倍时，检查点操作可以无需任何降级，以最大带宽Bwmax进行，如图3所示。检查点周期结束后，若Burst Buffer处于空闲状态，则执行降级操作。
模式2：在特定时间段内与检查点并行执行降级
当DWPP超过Burst Buffer容量S的1.0倍时，部分Burst Buffer中的数据需与检查点操作同步进行降级。降级操作的启动时间取决于DWPP的具体值。例如，当DWPP达到1.2S时，降级阈值设定为已使用Burst Buffer空间的70%，即DWSF的0.7S。换言之，当Burst Buffer使用率达到70%时，即便在执行检查点操作，也应启动降级过程。此时，检查点吞吐量在Bwmax和Bwmin之间调整，以适应降级操作的需要，同时降级吞吐量也在Brmin和Brmax之间相应变化。
模式3：降级始终与检查点并行执行
当DWPP超过某一特定值时，降级操作需始终与检查点操作同步进行。如图3所示，当DWPP超过1.35S时，降级操作必须在检查点周期的开始阶段立即启动。在此情况下，降级操作以最大吞吐量Brmax执行，而检查点操作在Burst Buffer使用率超过60%时，则以最小吞吐量Bwmin进行。
利用方程(3)和给定的DWPP值，我们可以计算出开始降级的Burst Buffer阈值容量以及相应的降级带宽。由于需要避免对下一个检查点周期的检查点操作造成干扰，所有Burst Buffer上的数据都需进行降级。因此，两个检查点周期之间所需的最小空闲时间可通过方程(4)进行计算。
B. 数据放置策略
在这项研究中，我们设计了一种创新的数据放置策略，该策略充分考虑了检查点和重启操作的特性。新策略旨在尽量延长最新的检查点文件在Burst Buffer中的保留时间，从而避免了频繁地从持久文件系统（PFS）预取数据到Burst Buffer的需求。具体而言，我们根据检查点文件的版本和高性能计算（HPC）应用程序的故障率来评估数据的热度。旧版本的检查点文件被赋予了最高的优先级，因为最新版本的检查点数据同样存放在Burst Buffer中。如果Burst Buffer中没有剩余的旧版本检查点文件，我们会参考写入检查点文件的应用程序的故障率来识别冷数据。由于HPC用户倾向于保留大量的Burst Buffer节点以预防故障，我们假设应用程序的故障率与其使用的Burst Buffer节点数量呈正相关。
C. 直接在PFS上进行检查点
我们还可以利用PFS的I/O能力，进一步提升Burst Buffer的工作效率。考虑到Burst Buffer中的冷数据最终会存储在PFS中，因此无需先将这些数据写入Burst Buffer。于是，在数据管理策略中，我们增加了一个绕过Burst Buffer的选项，当数据被判定为比Burst Buffer中已存储的其他数据更冷时，便可直接应用此选项。之所以能够实现这一点，是因为我们可以从日志历史中预先获取所有传入检查点数据的故障率。我们始终通过比较故障率与Burst Buffer上其他检查点文件的故障率，来判断检查点数据是热数据还是冷数据。一旦传入的检查点数据被判定为冷数据，我们便会指示将其直接写入PFS。这样一来，不仅减少了需要写入Burst Buffer的降级数据量，同时也减少了检查点与降级操作的并行执行。
IV. 设计与实现
我们提出了一种新颖的HPC数据管理方法——Burst Buffer超额分配方案（BBOS），旨在提升Burst Buffer的利用率，同时确保高效的检查点和重启性能。图4展示了BBOS框架的总体架构。该方案主要由两个引擎构成：I/O引擎和数据管理引擎，同时辅以一个内存键值存储，协助引擎进行高效处理。
A. I/O引擎
在采用BBOS方案的系统中，HPC应用程序作业的I/O操作由BBOS I/O调度程序进行统一调配。由于采用了超额分配方法，访问Burst Buffer的I/O作业数量增加，这可能导致严重的I/O拥堵，从而影响I/O性能。多个I/O作业之间若存在资源竞争和相互干扰，将降低作业的整体运行效率。因此，我们需要以尽可能避免重叠的方式对I/O作业进行调度。
BBOS I/O引擎为每个Burst Buffer节点设置了多个I/O队列，并为每个应用程序分配了独立的队列。这样，不同应用程序的I/O作业可以访问不同的I/O队列。调度程序通过循环轮询的方式从各个I/O队列中选取I/O作业，确保作业之间的执行尽可能不重叠。
同时，I/O引擎还管理着多个I/O工作线程，负责执行I/O作业。它们借助内存键值存储来确定每个待调度的I/O作业应访问的存储层，即Burst Buffer或持久文件系统（PFS）。通过这样的管理方式，我们可以更有效地利用系统资源，提高I/O操作的效率。
B. 数据管理引擎
数据管理引擎由四大模块构成：调节器、降级器、删除器和复制器。调节器负责动态地调整检查点和降级操作的带宽，确保系统资源的合理分配。降级器则根据检查点文件的版本以及应用程序的故障率，将数据从Burst Buffer逐步迁移至PFS，实现数据的合理存储。在BBOS数据管理系统中，已降级的数据会以缓存的形式暂存于Burst Buffer，直至无空间可供新的检查点文件写入。当Burst Buffer空间不足时，删除器会及时清理已降级完毕但仍占用空间的数据。最后，复制器会将检查点文件从本地PFS节点的存储设备复制到同一复制组内的远程PFS节点，确保数据的完整性和一致性。
C. 内存键值存储
我们采用了开源的内存键值存储Redis [29]，以辅助BBOS框架中的I/O和数据管理引擎运行。由于BBOS不使用页面缓存进行检查点和重启操作，内存存储可以充分利用未使用的内存资源，并提升BBOS引擎的执行效率。BBOS将检查点文件的数据路径以及用于数据放置所需的元数据信息存储在Redis内存数据库中。基于存储的数据，降级器会优先降级最老的检查点文件。若Burst Buffer中存储的检查点文件均为最新版本，降级器则会从故障率最高的文件开始降级。此外，DWPP和DWSF等关键数据也存储在数据库中，以便实时决定降级阈值并持续跟踪调整检查点和降级的带宽。BBOS内存键值存储中使用的九个键值对详见于表1，具体解释请参见第IV-F节。
| 键 | 值 | 描述 |
| FileName | String(path) | 记录Burst Buffer和PFS中每个文件的存储路径 |
| "VICTIM' | Sorted Set(MTBF, AppID) | 记录受影响的应用程序的ID，并按照平均无故障时间（MTBF）进行排序 |
| "CLEAN" | List(AppID) | 列出那些包含demotion-finished文件的应用程序ID，以便在Burst Buffer需要释放空间时进行清理 |
| "APP" | List(AppID) | 记录在Burst Buffer中存储有两个或更多不同检查点版本的应用程序ID列表 |
| "DWSE" | String(DWSF) | 记录用于限制检查点/重启操作带宽的DWSF信息 |
| "REPLICA' | List(FileName) | 列出需要复制的文件清单 |
| AppID+"restart" | Sorted Set(MTBF,time) | 记录每次读取请求的重启时间及更新后的平均无故障时间（MTBF） |
| AppID+deviceID | Sorted Set(ver, FileName) | 记录每个HPC应用程序在每个设备上的检查点文件的版本和名称 |
| AppID+"BB" | NULL | 若应用程序的检查点文件存放在Burst Buffer中，则记录下该应用程序的ID |
表1. BBOS中内存键值存储所使用的键值对列表。
D. 稳定检查点和降级性能的优化设计
为确保检查点、重启及降级性能的稳定性，我们采用了多项技术优化数据管理策略。首先，利用BBOS引擎动态调节检查点与降级的带宽，以适应不同应用场景的需求。然而，在复杂的HPC系统中，精确控制I/O带宽仍具挑战性。由于各应用程序作业的I/O需求差异较大，实际检查点带宽可能与预期策略存在偏差。此外，降级数据量的不确定性也可能影响检查点性能的稳定性。因此，我们借助Linux内核的cgroup blkio [30]控制器，实现对检查点及重启操作速度的精确控制。其次，采用send_file()系统调用[31]确保降级性能的稳定性。在降级过程中，需从Burst Buffer读取数据并写入PFS，此过程涉及用户级与内核级间的上下文切换和数据复制，易导致性能下降。send_file()系统调用的零拷贝特性可有效消除降级过程中的额外开销。最后，针对垃圾收集可能导致的性能偶发性下降问题，我们在删除文件后定期触发TRIM命令，并利用blkio控制器控制TRIM的吞吐量，从而最大程度减少性能损失。
E. 利用持久性内存的优化设计
我们进一步通过采用持久性内存技术，对BBOS进行了优化。非易失性双列直插内存模块（NVDIMM）是一种创新的内存模块，它将DRAM和存储技术巧妙地融合在DIMM插槽中。HPC超级计算机系统通过使用NVDIMM，能够以更低的成本享受到接近内存速度的I/O性能。在BBOS中，我们使用了Redis内存键值数据库来跟踪与I/O相关的元数据。每当进行I/O访问Burst Buffer时，Redis都会更新多个键值对，并依据这些信息来确定检查点文件的位置或调整读写带宽。因此，在I/O操作过程中会产生大量的内存访问。为了降低内存开销并提高数据持久性，我们结合了NVDIMM与Redis的优势。
具体来说，我们采用了支持持久性内存的Redis版本——pmem-redis [32]，以提供高性能和持久性的数据存储。在pmem-redis的众多功能中，我们特别挑选了两个功能，将其应用于BBOS框架中。利用NVDIMM的BBOS内存键值存储的整体架构如图5所示。
首先，鉴于NVDIMM作为一种低成本内存，我们实施了一种数据放置策略，将键值对分别存储在DRAM和NVDIMM上。由于大多数HPC应用程序都是内存密集型工作负载，在访问Burst Buffer资源时往往需要消耗大量的内存容量。当BBOS管理Redis数据库时，由于数据是从内存中获取的，这会增加内存的使用量。因此，为了不干扰HPC应用程序的I/O带宽，Redis必须控制其内存消耗。为了扩展Redis可使用的内存容量，pmem-redis提供了一种将大值存储在NVDIMM中的功能。这是因为相比小数据和随机数据访问模式，NVDIMM在大数据和顺序数据访问模式下展现出比DRAM更出色的性能。通过这种方式，我们可以在保持DRAM般大数据访问速度的同时，减少Redis在DRAM上的使用量。具体来说，所有大小超过64B的值默认存储在NVDIMM中，而键和小值则存储在DRAM中。尽管与DRAM相比，NVDIMM具有更高的延迟，但我们的实验表明，当应用程序在Burst Buffer上进行I/O操作时，pmem-redis的开销几乎可以忽略不计。
其次，NVDIMM具有硬盘的特性，即存储在持久性内存中的数据在断电和重新启动后依然保留。Redis中存储的信息对于Burst Buffer调度程序的正常运行至关重要。此外，每当应用程序请求检查点或重新启动操作时，Redis中的键值对有助于准确定位正确的文件，并确保其他I/O请求获得合理的I/O带宽。传统的Redis提供了两种数据持久性机制来保护数据库中的数据：RDB持久性定期将内存中的所有数据写入磁盘，而AOF持久性则将服务器发出的每个插入、修改、删除命令记录到磁盘中。然而，这些持久性方法的一个主要缺点是数据必须写入速度较慢的硬盘。当发生停电并在重新启动过程中需要从慢速磁盘读取数据时，这会导致性能下降。为了提高Redis的持久性能，pmem-redis将持久性文件写入NVDIMM的预留空间。当持久性数据大小超过预留空间时，我们采用LRU策略来驱逐数据。这样一来，周期性持久性操作可以获得更高的写入带宽，而且在停电发生时，可以像访问DRAM一样快速地读取持久性文件。
F. 实现
在本节中，我们将详细阐述在BBOS框架中，使用Redis内存键值存储进行各个引擎操作的流程。BBOS框架通过改进Gluster文件系统（GlusterFS），一个具备高度可扩展性的分布式文件系统来实现这一目标。我们向GlusterFS中加入了I/O引擎和数据管理引擎，使它们能够与工作流程的关键环节进行交云处理。同时，GlusterFS也与Redis服务器紧密互动，收集Burst Buffer调度策略所需的信息。
Redis内存键值存储中共包含9种键值对，详列于表1。Redis负责记录所有写入和读取Burst Buffer的文件的元数据信息。首先，Redis存储了在Burst Buffer和PFS中写入的每个文件的文件路径，这样数据管理引擎便能迅速定位到需要降级或读取的文件。每个由HPC应用程序写入的检查点文件，GlusterFS会在I/O流中为其分配一个特定的应用程序ID，我们称之为App ID。当Burst Buffer空间不足时，我们利用键名“VICTIM”管理的Sorted Set来识别哪些检查点文件需要降级到PFS。这个排序集合按照MTBF（平均故障间隔时间）顺序排列App ID，反映了每个应用程序的故障率。键“CLEAN”则记录了已完成降级操作的检查点文件所对应的应用程序列表，这些文件在Burst Buffer中的存储可以删除。键“APP”管理了那些在Burst Buffer中存储了两个以上不同版本检查点文件的应用程序，当空间不足时，这些旧版本文件将被删除。此外，键“DWSF”记录了检查点I/O阶段至今写入的数据量，用于计算检查点和降级带宽。键“REPLICA”管理了需要在远程存储节点上复制的文件列表。AppID后接“restart”的键记录了重启时间和新的MTBF，每次读取检查点文件时都会更新。AppID与deviceID组合的键则记录了每个Burst Buffer设备中存储的检查点文件的版本和名称，便于追踪文件的降级情况。最后，AppID后接“BB”的键记录了BBOS引擎能够检查应用程序的检查点文件是否之前已写入Burst Buffer。
利用Redis数据库中存储的信息，BBOS框架的I/O引擎和数据管理引擎提升了Burst Buffer的利用率，同时保证了稳定的性能。接下来，我们将详细介绍使用这九对键值的BBOS框架的实现细节。
I/O引擎负责调度I/O作业，并为每个检查点文件找到合适的存储层。算法1展示了检查点操作流程的伪代码。除非没有足够的空间存放新的检查点文件，否则降级数据可以保留在Burst Buffer中。因此，在处理检查点操作前，I/O引擎会首先检查剩余空间。如果空间不足，引擎会向删除器（Deleters）发送信号，以删除已完成降级的文件或过时文件（行1-2）。此外，引擎还会检查Burst Buffer中是否存在应用程序的过时检查点文件。安全写入新检查点文件后，旧版本文件便不再需要保留在Burst Buffer中。为找出过时文件，引擎会检查Redis数据库中是否存在应用程序的相应键（第9对）。若键存在，引擎会将应用程序添加到第4对中，以便删除器稍后处理过时文件（行3-4）。接着，引擎列出每个应用程序的检查点文件名及其存储的设备ID（行5）。同时，引擎将每个文件名的文件路径保存在第1对中（行6）。检查点操作完成后，引擎会更新当前文件大小到第5对中（行7-8）。由于我们的系统会将完成降级的数据保留在Burst Buffer中，直到实际需要释放空间，因此持续记录DWSF值对于保持Burst Buffer的容量完整性至关重要。若在检查点阶段不跟踪DWSF，BBOS将无法准确了解实际写入的数据量。
重新启动操作的流程如算法2所示。当系统发生故障并需要重新启动时，会更新两个新值以供Demoters选择需要降级的文件。首先，从第7对中读取需要重新启动的应用程序的MTBF（平均故障间隔时间）和最新的重新启动时间（行1）。接着，模块会计算新的MTBF并更新第7对中的值（行2-3）。同时，引擎会检查应用程序的检查点文件是否存储在Burst Buffer上，这需要使用第9对中的信息。如果待读取的检查点文件确实存储在Burst Buffer上，那么引擎会使用新的MTBF来更新第2对中的值（行4-5）。完成所有流程后，引擎会通过第1对来读取应用程序的检查点文件（行6-7）。
当I/O引擎调度访问Burst Buffer的I/O作业时，数据管理引擎会使用四个模块来高效管理Burst Buffer和PFS之间的降级过程。首先，Throttler通过监控DWSF（已写入数据量）来调节检查点和重新启动操作的带宽。它会从第5对中获取DWSF，并根据情况决定是否启动降级。一旦DWSF超过设定的降级阈值，Throttler就会调整检查点和重新启动的带宽至重新配置的数值。
接下来，Demoters会接收Throttler发出的信号，了解哪些Burst Buffer中的设备需要进行降级。随后，Demoters会从内存存储中收集所需信息以执行降级操作。具体的降级过程如算法3中的伪代码所示。Demoters首先会检查第4对中的受害者检查点文件，因为这些通常是最旧版本的检查点文件，应优先进行降级（行1）。如果没有找到受害者文件，则会在第2对中进行查找，这些文件是按MTBF排序的（行2-3）。即使受害者是某个应用程序的最新检查点文件，也必须进行降级。如果从第2对中找到受害者文件，那么在完成降级后，该文件不会从Burst Buffer中删除，而是同时保留在Burst Buffer和PFS中，以确保重新启动时的性能（行7-8）。但为了避免占用过多的Burst Buffer空间，该受害者文件会在第3对中被标记，以便在需要释放空间时能够擦除（行9）。如果从第4对中找到受害者文件，这意味着该应用程序存在旧版本的检查点文件，这些文件不需要保留在Burst Buffer中，因此可以删除（行10-11）。最后，Demoters会更新第1对中的信息（行12），并将文件名放入第6对中，以便Replicators进行后续的复制操作（行13）。
第三，当Deleters收到来自I/O工作线程的信号后，会负责擦除已经完成降级的文件。具体操作是，Deleters首先从第3对中取出应用程序的信息，然后使用第1对和第8对中的信息从Burst Buffer中删除这些文件。
最后，Replicators负责将检查点文件从本地存储设备复制到同一复制组中的远程设备。每个存储节点都有一个PFS的挂载点，这个挂载点包括了同一复制组中的其他存储节点，但不包括该节点自身。此外，为了提升数据传输效率，每个存储节点之间还额外安装了专用的低速网络。因此，Replicators会使用第6对中的信息将降级数据传输到相应的挂载点，从而避免对Burst Buffer的性能造成干扰。
V. 评估
A. 实验环境
我们在一个小规模的测试环境中，该环境由八个计算节点和一个单独的存储节点组成，对BBOS HPC存储管理方案进行了评估。在存储节点中，我们配置了Burst Buffer和PFS。其中，四个计算节点搭载了Intel Xeon Phi CPU 7290处理器，每个拥有72个物理核心；另外四个计算节点则采用了Intel Xeon Phi CPU 7250处理器，每个包含68个物理核心。存储节点方面，我们选用了双路12核的Intel Xeon Silver CPU 4115，并为其配备了32 GB的内存。
Burst Buffer使用了由一家半导体初创公司提供的四块800 GB FADU NVMe SSD，其顺序写入和读取性能分别高达920 MB/s和3,200 MB/s。为了增加内存容量并提升Redis内存数据库的数据持久性，我们在存储节点中部署了16GB Dell NVDIMM-N。此外，与Burst Buffer处于同一存储节点的PFS，则是由四块4TB Samsung 860 EVO SATA SSD构成。计算节点与存储节点之间，我们采用了100 GbE Mellanox SN2100交换机进行连接。
在配置Burst Buffer和PFS时，我们选用了GlusterFS版本5.6，并针对文件系统配置进行了调整，以追求更高的性能。为了适应BBOS方案，我们还对GlusterFS进行了修改，增加了多个模块。考虑到存储设备所提供的可行I/O带宽，我们为BBOS框架的每个变量配置了相应的值：Bwmax设为3.56 GB/s，Bwmin设为3 GB/s，Brmax设为1.6 GB/s，Brmin设为0.08 GB/s，并设定周期为3800秒。
为了进行实验，我们采用了微基准测试工具FIO，进行了大规模的顺序写入I/O操作，以模拟检查点操作的场景。值得注意的是，由于故障率与MTBF（平均故障间隔时间）之间存在反比关系，因此在此次评估中，我们采用了MTBF作为应用程序故障率的指标。
为了更全面地评估BBOS的性能，我们将其与DataWarp进行了对比。DataWarp是目前部署的一种HPC调度程序，它采用了专用的Burst Buffer分配机制，并结合了Harmonia中提出的两种调度策略。Harmonia作为一种新型的调度程序，采用了Burst Buffer过度订阅的方法。鉴于Harmonia并非开源项目，我们根据相关论文制作了一个仿真调度程序。在功能方面，DataWarp并不执行I/O调度，而Harmonia则对I/O作业进行调度，以避免它们相互干扰。MaxEff是Harmonia中的一个调度策略，它通过最大化Burst Buffer的利用率来优化系统效率。由于该策略旨在保持Burst Buffer的高空闲空间，因此在同时执行检查点时，它也能以全速（Brmax）进行数据的降级处理。另一方面，Harmonia中的另一个策略MaxBW则旨在为应用程序提供最大的检查点带宽。在使用MaxBW调度策略时，检查点和降级操作不能同时进行。在图3中，MaxEFF的降级阈值设定为DWSF的0秒，而MaxBW的阈值则设定为DWSF的1秒。
B. Burst Buffer利用率
在这一部分，我们针对Burst Buffer的利用率，采用了四种不同的调度策略进行了评估。我们设定了一个场景，即每个应用程序在每个周期内需要写入一个80GB的检查点文件。Burst Buffer的利用率主要取决于周期内成功完成检查点文件写入的应用程序数量，这同时也反映了各调度策略所能提供的最大DWPP。这四种调度策略的Burst Buffer利用率已在图6中进行了展示。
DataWarp由于其根据用户需求采用专用分配方法来分配Burst Buffer容量，因此展现了0到100%的利用率变化。理想情况下，检查点周期内Burst Buffer的总容量能够被完全利用，即便所有用户的Burst Buffer分配需求都能得到满足，这时利用率将达到100%。然而，由于大多数情况下Burst Buffer的容量请求超出了实际可用量，导致其利用率仍然偏低。
相比之下，Harmonia和BBOS则能够通过采用过度订阅的Burst Buffer分配方法，使Burst Buffer在周期内能够容纳更多的I/O请求。其中，MaxBW调度策略不允许在检查点执行时进行降级操作，以确保应用程序能够获得最大的检查点吞吐量。因此，使用MaxBW可以实现高达190%的Burst Buffer利用率。
而MaxEff则展示了210%的Burst Buffer利用率，这是因为它总是以最大的降级吞吐量进行降级操作，尽管这可能会带来检查点性能的降低风险。BBOS与MaxEff类似，其降级操作可以在任何可能的时间进行，无需受检查点操作的干扰。因此，使用BBOS同样可以将Burst Buffer的利用率提升至210%。
C. 检查点性能
低：每个I/O作业的时间间隔相等且均匀分布在周期内。 中：每个I/O作业的时间间隔为低情况的一半。 高：每个I/O作业的时间间隔仅为低情况的十分之一。
以低I/O拥塞率为例，若每隔50秒请求一次I/O作业，那么在中、高I/O拥塞率下，I/O作业的到达频率将分别提升至每隔25秒和5秒一次。为了简化分析，我们假设所有应用程序在每个周期内均请求一次80GB的检查点文件。
图7展示了不同I/O场景下检查点的吞吐量和延迟情况。这些延迟包括：等待上一个作业完成的时间，以防I/O作业并发执行；等待空闲Burst Buffer空间被保留的时间；以及I/O作业的实际执行时间。在I/O作业间存在足够空闲时间时，DataWarp可利用这些时间将数据写入检查点进行降级。因此，在低I/O作业拥塞率下，DataWarp能够提供较高的检查点吞吐量。然而，在高I/O作业拥塞率下，由于I/O作业接连不断，没有足够的时间释放Burst Buffer空间，导致检查点吞吐量保持较低水平。
与DataWarp不同，Harmonia和BBOS通过优化I/O作业的调度来减少跨作业间的I/O干扰。由于MaxBW策略禁止降级与检查点同时执行，因此它能确保高检查点吞吐量。但即便如此，仍有一些I/O作业需要等待可用的Burst Buffer容量。在低拥塞率场景下，由于I/O作业间有足够的空闲时间，应用程序无需等待以避免I/O干扰或为Burst Buffer空间让路。然而，随着I/O作业的集中到达和DWPP的增加，部分应用程序开始面临较高的延迟。特别是在中等I/O作业拥塞率且DWPP超过1.6S的情况下，Harmonia和BBOS的检查点延迟开始显著上升。较大的DWPP意味着作业间空闲时间减少，进而导致检查点延迟随DWPP的增加而增加。在高I/O作业拥塞率时，作业需等待更长时间，造成最高检查点延迟。
此外，MaxBW策略表现出极大的性能波动。图8展示了在DWPP为1.9S的中等I/O拥塞率下，前45个I/O作业的等待时间。后续到达的I/O作业需长时间等待，导致性能严重波动。相对而言，BBOS策略确保提前降级数据，使Burst Buffer始终为即将到来的作业预留空间。在BBOS方案下，等待时间从实验开始就逐渐上升，避免了等待时间的突然激增。总的来说，当没有等待时间时，MaxBW性能更优。然而，在每周期Burst Buffer空闲时间或I/O作业间空闲时间不足时，MaxBW表现出比BBOS更高的延迟和性能波动。这是因为BBOS始终为最坏情况做准备，通过调整检查点性能来提前为Burst Buffer保留空间。
MaxEff和BBOS都采取了提前降级的策略，以避免Burst Buffer溢出。MaxEff之所以展现出最低的检查点吞吐量，是因为它总是以最大速度进行数据降级。这样一来，就能保持较大的Burst Buffer容量。因此，与MaxBW相比，MaxEff的检查点延迟更低。而BBOS则根据DWPP来调整检查点吞吐量，在Bwmax到Bwmin的范围内灵活变动。DWPP越小，通过避免不必要的检查点与降级并发执行，BBOS就能实现更高的检查点吞吐量。当有足够的时间释放Burst Buffer容量时，影响延迟的主要因素便是检查点吞吐量。因此，当DWPP较小时，BBOS相较于MaxEff展现出了更低的检查点延迟。虽然MaxEff在降级上更为积极，但当DWPP较大时，MaxEff的检查点延迟却高于BBOS。这是因为MaxEff始终以最大速度降级数据，为达到这一速度，不得不牺牲部分检查点吞吐量，导致检查点I/O作业等待时间更长。在我们的实验中，MaxEff和BBOS的延迟差异并不显著，约为几十秒，这主要得益于Bwmax和Bwmin之间的差异不大。若差异扩大，我们预期BBOS的I/O延迟将较MaxEff有显著降低。
总的来说，BBOS是一种新颖的方法，它有效弥补了MaxBW和MaxEff的不足。通过根据DWPP和I/O作业拥塞率动态调整检查点和降级速度，BBOS始终能够保持较高的检查点吞吐量和较低的延迟，相较于其他方法更具优势。此外，我们的实验结果显示，在Burst Buffer上运行BBOS框架并未产生额外的I/O开销。换句话说，应用程序可以根据BBOS I/O调度器的决策灵活调整检查点和重启操作的速度，从而获得预期的I/O性能。因此，BBOS不仅适用于单个Burst Buffer节点系统，也能在拥有数千个存储节点的真实世界HPC系统中有效调整作业的检查点吞吐量。由于BBOS运行时采用了预先设定的系统配置，它能在硬件限制下提供稳定的检查点性能。
D. 直接在PFS上进行检查点
当PFS与Burst Buffer提供的I/O带宽差异不大时，直接访问PFS而绕过Burst Buffer能有效避免不必要的降级开销。我们针对三种不同的DWPP——1.3S、1.6S和1.9S进行了实验。每个应用程序每小时会请求一个80GB的检查点，同时所有应用程序的MTBF（平均故障间隔时间）均随机设置在0到100分钟之间。为了优化BBOS框架，我们特别关注了发出检查点请求的应用程序的MTBF。
在提供服务前，I/O引擎会先检查Burst Buffer的容量使用情况。只有当需要降级以释放空间时，引擎才会进一步判断即将写入的检查点文件是否为冷数据。这一判断基于应用程序的故障率与同一应用程序的检查点文件之间的版本号对比。由于故障可能性较低，MTBF较大的应用程序在写入时更可能被视为冷数据。此外，当存在多个版本不同的检查点文件时，只有最新版本被视为热数据。
若需写入冷数据而Burst Buffer空间不足时，优化后的BBOS会选择绕过Burst Buffer，直接在PFS上进行写入。图9展示了在不同DWPP场景下，使用优化BBOS后的规范化降级数据大小。在DWPP为1.9S的情况下，大量被视为冷数据的检查点文件直接写入PFS，使得降级数据量减少了高达38%。由于检查点操作中降级的数据量减少，更多应用程序能够享受到更高的检查点吞吐量。
E. 重启性能
我们评估了Burst Buffer上的重启性能，通过比较使用不同调度策略（LRU、FIFO和BBOS）时的命中率。DWPP被设定为1.5S、1.7S、1.9S和2.1S，同时，我们随机设置了应用程序的MTBF（平均故障间隔时间）范围，分别为：0到20分钟（低）、0到50分钟（中）和0到100分钟（高）。在选择需要重启的应用程序时，我们考虑了预期的MTBF，因为故障率与MTBF成反比。所有检查点周期都被设置为相同，且每个应用程序的检查点大小均为80 GB。
图10展示了不同配置下的命中率情况。在所有情况下，BBOS在Burst Buffer上均显示出最高的命中率。由于检查点文件在低DWPP的情况下更可能存储在Burst Buffer中，因此，三种调度策略的命中率均随着DWPP的降低而增加。然而，在LRU和FIFO算法中，冷数据的选择是基于写入时间顺序的，导致每个实验的命中率波动较大，且结果与MTBF的波动无直接关联。与之相反，BBOS的命中率则随着MTBF波动的增大而增加。
当MTBF波动较小时，我们系统的有效性相对较低，因为此时应用程序的故障率较为接近。另一方面，在MTBF波动较大的情况下，根据MTBF的故障率对Burst Buffer和PFS上的检查点文件进行了合理分布，使得排序更为有效。因此，与其他方法相比，BBOS在Burst Buffer上提供的重启请求的命中率最多提高了3.4倍。
F. 版本感知的数据放置
为了维持Burst Buffer上的高命中率，BBOS采用了版本感知的数据放置方法，将不再需要的检查点文件识别为冷数据。为了验证版本感知数据放置方法的有效性，我们为应用程序设置了三个不同的检查点周期：60分钟、30分钟和20分钟。每个用户将请求一个大小为80 GB的检查点数据，应用程序的MTBF（平均故障间隔时间）则在0到100分钟范围内随机设定。我们假设应用程序会保留三个或更多版本的检查点文件。因此，具有60分钟周期的应用程序在一小时内会生成一个检查点版本，30分钟周期会生成两个版本，而20分钟周期则会有三个版本。我们还设置了应用程序数量的比例为1:1:1和5:2:1，并固定DWPP为1.9S。
图11展示了在使用和不使用版本感知方法的情况下，Burst Buffer上重启请求的命中率。当具有不同检查点周期的应用程序数量相同时，通过版本感知方法，所有最新的检查点文件都可以被存储在Burst Buffer中，理想情况下的命中率达到了96.4%。然而，我们的结果显示命中率略有下降，这是因为即使需要释放Burst Buffer空间来处理传入的I/O请求时，具有最高MTBF的检查点文件（尽管它是最新的）也必须进行降级。当不使用版本感知数据放置方法时，冷数据的判断仅基于应用程序的MTBF，这可能导致具有高MTBF的最新检查点文件被存储在PFS上，而具有低MTBF的旧版本文件却保留在Burst Buffer中。因此，在评估中，不使用版本感知方法的命中率仅为80.1%。
在比例为5:2:1的情况下，由于存在大量具有低检查点周期的应用程序，所有检查点文件无法全部存储在Burst Buffer中。通过使用版本感知放置策略，我们可以在Burst Buffer中处理92.5%的重启请求，而在不使用该策略的情况下，只能处理71.7%的请求。这充分证明了版本感知数据放置方法在提高Burst Buffer命中率方面的有效性。
G. 使用NVDIMM的BBOS性能
BBOS框架在Redis内存数据库上采用NVDIMM进行了进一步的优化。本节将展示两个评估结果：具备NVDIMM感知能力的Redis数据库性能以及应用NVDIMM后BBOS框架中Burst Buffer的I/O性能。
首先，为了专注于持久性内存下Redis的性能表现，我们采用了memtier benchmark[37]工具，并对默认Redis与pmem-redis版本进行了性能对比。请求数据大小范围设置为64B至256B，这是基于实际经验的选择，因为在BBOS框架中，Burst Buffer为检查点和重启操作提供服务时，Redis的读写数据大小保持一致。我们设置了GET与SET操作的比例为10:0、0:10和5:5，请求数量则分别为5,000、10,000和20,000。图12呈现了默认Redis与NVDIMM下Redis的事务率对比。每个键都保留在DRAM中，而大于64B的值则写入NVDIMM。由于在我们的配置中，每个值的大小均超过64B，因此所有值均保存在NVDIMM中。尽管这种方法节省了DRAM空间，但将值数据从DRAM移至NVDIMM需要额外的数据复制操作。此外，与DRAM相比，NVDIMM的数据读写延迟较长。因此，pmem-redis版本的性能相较于默认Redis下降了0.4%至15.7%。
接下来，我们评估了应用NVDIMM的BBOS框架中Burst Buffer的I/O性能。图13展示了在单个Burst Buffer节点上运行BBOS并使用NVDIMM下Redis时，随时间变化的聚合磁盘I/O速率。图中红色虚线表示未使用NVDIMM时Burst Buffer的平均I/O性能。此次评估未对I/O性能设限。结果显示，即使在Redis将大部分数据存储在NVDIMM中的情况下，重载I/O负载下的磁盘I/O速率依然保持稳定。换言之，使用持久性内存的Redis优化版本对I/O工作负载带宽的影响微乎其微。总体来看，尽管pmem-redis版本的性能有所下降，但考虑到Burst Buffer的I/O带宽仍能达到最大性能限制，这一性能损失是可以接受的。
当大量突发I/O进入搭载BBOS框架的Burst Buffer系统时，不仅数据在多层之间的移动会增加内存使用量，而且用于管理I/O操作的数据复制和文件系统进程同样会消耗更多内存。在由数千个计算节点和存储节点构成的真实世界HPC系统环境中，内存消耗将急剧上升，最终影响整个系统的性能。因此，保持充足的空闲内存至关重要。考虑到NVDIMM能够以较低成本轻松扩展内存容量，我们的解决方案能够在维持I/O性能的同时确保足够的内存空间。
VI. 相关工作
过去几年里，Burst Buffer已在众多HPC存储系统中得到广泛应用，显著提升了系统的I/O性能。大量科学HPC应用程序因此受益，充分利用了Burst Buffer提供的高性能I/O能力[10]，[38]。在架构设计上，Burst Buffer可以灵活部署，既可以置于计算节点内部，也可以作为独立的专用Burst Buffer节点存在[11]，[39]，[40]。在HPC系统中，常见的Burst Buffer设计是共享式组织，与本地式设计相比，共享式往往能展现出更出色的I/O性能[41]。为了进一步优化Burst Buffer系统，HPC社区已投入大量研究，采用了多样化的方法。
鉴于Burst Buffer在HPC存储系统中作为缓存层的关键作用，多项研究聚焦于Burst Buffer框架的优化技术。Khetawat等人[42]设计了一个模拟框架，能够准确找到针对现实世界HPC工作负载的I/O特性的最佳Burst Buffer配置。Aupy等人[43]则通过运用多项式时间算法对Burst Buffer的大小和分区进行优化，有效减少了I/O冲突。随着Burst Buffer作为高性能缓存层的广泛应用，研究人员也开始关注如何利用它来改善检查点和重启性能。其中，一种策略是将检查点文件写入包括计算节点、Burst Buffer和PFS在内的多个层级[44]。为了降低PFS上的检查点开销，Moody等人[25]开发了一种多级检查点机制，它综合考虑了HPC存储系统中各层级的可靠性和检查点成本。Dong等人实现的Data Elevator[45]则通过转移I/O访问从Burst Buffer到PFS，减少了Burst Buffer上的争用情况。与需要用户指定数据最终目标的Data Elevator不同，BBOS在Burst Buffer空间不足时，能够动态管理对PFS的直接检查点。考虑到多级检查点可能在高规模HPC环境中导致较高的故障率，Sato等人[46]结合了多级检查点与非阻塞机制，实现了检查点操作中数据的异步传输。与先前研究类似，我们的工作也致力于提升多层HPC系统中Burst Buffer上的检查点和重启性能。
在适当的I/O调度策略支持下，Burst Buffer的性能可以得到进一步发挥，这与现有的PFS策略相似[27]，[47]，[48]。Han等人[28]观察到，当多个HPC用户同时使用Burst Buffer时，其I/O能力往往无法得到充分利用。为此，他们提出了基于多流SSD的Burst Buffer方案，通过为每个用户分配独立的I/O流来消除I/O干扰。Koo等人[49]则通过提出基于流的调度策略，进一步优化了Burst Buffer上的I/O分离方案。Thapaliya等人[47]也报告了共享Burst Buffer系统中存在的I/O干扰问题，而Gainaru等人[50]尝试根据作业的过往I/O模式进行动态调度。TRIO是一种有效的Burst Buffer I/O调度策略，能够将I/O流量从Burst Buffer转移到PFS[2]。与上述工作类似，BBOS引入了一种新颖的I/O调度策略，有效处理了考虑检查点特性的数据在Burst Buffer和PFS之间的传输。
一些研究指出，HPC应用程序中存在频繁访问的数据，包括检查点文件[3]，[51]。通过将热数据放置在Burst Buffer上，I/O密集型应用程序能够从中获益。Shin等人[15]采用目标驱动的数据管理方案，实现了数据在HPC多层存储系统上的自动放置。而Shi等人[52]则通过利用应用程序的写访问模式来调节Burst Buffer和PFS上的I/O流量。我们的工作在决策数据放置时，也充分考虑了I/O模式和检查点操作的特性。
VII. 结论
BBOS是一种专为基于Burst Buffer的HPC存储系统设计的新型I/O调度框架。它通过仅在I/O阶段分配Burst Buffer的方式，运用超额调度策略，有效提升了Burst Buffer的利用率。为了缓解性能下降的问题，BBOS集成了Burst Buffer感知的I/O调度器和数据管理模块。我们深入分析了检查点和重启操作的特性，并据此设计了BBOS模块。基于这些特性，数据能够动态调整降级的阈值和速度，实现从Burst Buffer到PFS的透明转移。此外，我们还通过考虑检查点文件的不同版本和失败率，有效识别了冷数据。
所有与BBOS框架相关的元数据均通过Redis内存数据库进行处理，该数据库经过持久性内存的改进，进一步提升了性能。因此，与默认的专用Burst Buffer分配方法相比，BBOS将Burst Buffer的利用率提高了高达120%，并在不降低性能的前提下，确保了更高的检查点吞吐量。更值得一提的是，高达96.4%的重启请求可以在Burst Buffer中完成处理，而在BBOS框架下，重启性能更是高达3.1倍。
REFERENCES
[1] K. Sato, K. Mohror, A. Moody, T. Gamblin, B. R. D. Supinski, N. Maruyama, and S. Matsuoka, ‘‘A user-level infiniband-based file system and checkpoint strategy for burst buffers,’’ in Proc. 14th IEEE/ACM Int. Symp. Cluster, Cloud Grid Comput., May 2014, pp. 21–30.
[2] T. Wang, S. Oral, M. Pritchard, B. Wang, and W. Yu, ‘‘TRIO: Burst buffer based I/O orchestration,’’ in Proc. IEEE Int. Conf. Cluster Comput., Sep. 2015, pp. 194–203.
[3] T. Xu, K. Sato, and S. Matsuoka, ‘‘Explorations of data swapping on burst buffer,’’ in Proc. IEEE 24th Int. Conf. Parallel Distrib. Syst. (ICPADS), Dec. 2018, pp. 517–526.
[4] The ASC Sequoia Draft Statement of Work. Accessed: Mar. 8, 2022. [Online]. Available: https://asc.llnl.gov/
[5] N. Liu, J. Cope, P. Carns, C. Carothers, R. Ross, G. Grider, A. Crume, and C. Maltzahn, ‘‘On the role of burst buffers in leadership-class storage systems,’’ in Proc. 28th IEEE 28th Symp. Mass Storage Syst. Technol. (MSST), Apr. 2012, pp. 1–11.
[6] O. Yildiz, A. C. Zhou, and S. Ibrahim, ‘‘Eley: On the effectiveness of burst buffers for big data processing in HPC systems,’’ in Proc. IEEE Int. Conf. Cluster Comput. (CLUSTER), Sep. 2017, pp. 87–91.
[7] B. R. Landsteiner, D. Henseler, D. Petesch, and N. J. Wright, ‘‘Architecture and design of cray datawarp,’’ Cray User Group (CUG), 2016.
[8] X. Meng, C. Wu, J. Li, X. Liang, Y. Bin, M. Guo, and L. Zheng, ‘‘HFA: A hint frequency-based approach to enhance the I/O performance of multilevelcachestoragesystems,’’inProc.20thIEEEInt.Conf.ParallelDistrib. Syst. (ICPADS), Dec. 2014, pp. 376–383.
[9] H. Sung, J. Bang, C. Kim, H.-S. Kim, A. Sim, G. K. Lockwood, and H. Eom, ‘‘BBOS:Efficient HPC storagemanagement via burstbuffer oversubscription,’’ in Proc. 20th IEEE/ACM Int. Symp. Cluster, Cloud Internet Comput. (CCGRID), May 2020, pp. 142–151.
[10] W. Bhimji et al., ‘‘Accelerating science with the NERSC Burst buffer early user program,’’ in Proc. Cray User Group Meeting, 2016.
[11] T. Wang, K. Mohror, A. Moody, K. Sato, and W. Yu, ‘‘An ephemeral burstbuffer file system for scientific applications,’’ in Proc. Int. Conf. High Perform. Comput., Netw., Storage Anal. (SC), Nov. 2016, pp. 807–818.
[12] Cori Burst Buffer. Accessed: Jun. 1, 2022. [Online]. Available: https:// www.nersc.gov/users/computational-systems/cori/burst-buffer/
[13] DATAWARP. Accessed: Jun. 1, 2022. [Online]. Available: https://www. cray.com/products/storage/datawarp
[14] Slurm Workload Manager. Accessed: Jun. 1, 2022. [Online]. Available: https://slurm.schedmd.com/publications.html
[15] W. Shin, C. D. Brumgard, B. Xie, S. S. Vazhkudai, D. Ghoshal, S. Oral, and L. Ramakrishnan, ‘‘Data jockey: Automatic data management for HPC multi-tiered storage systems,’’ in Proc. IEEE Int. Parallel Distrib. Process. Symp., May 2019, pp. 511–522.
[16] R. A. Ashraf, S. Hukerikar, and C. Engelmann, ‘‘Shrink or substitute: Handling process failures in HPC systems using in-situ recovery,’’ in Proc. 26th Euromicro Int. Conf. Parallel, Distrib. Netw.-Based Process., 2018, pp. 178–185.
[17] J. W. Young, ‘‘A first order approximation to the optimum checkpoint interval,’’ Commun. ACM, vol. 17, no. 9, pp. 530–531, Sep. 1974.
[18] J. T. Daly, ‘‘A higher order estimate of the optimum checkpoint interval for restart dumps,’’ Future Gener. Comput. Syst., vol. 22, no. 3, pp. 303–312, Feb. 2006.
[19] G. Lu, Z. Zheng, and A. A. Chien, ‘‘When is multi-version checkpointing needed?’’ in Proc. 3rd Workshop Fault-Tolerance HPC Extreme Scale, 2013, pp. 49–56.
[20] S. Gupta, D. Tiwari, C. Jantzi, J. Rogers, and D. Maxwell, ‘‘Understanding and exploiting spatial properties of system failures on extreme-scale HPC systems,’’ in Proc. 45th Annu. IEEE/IFIP Int. Conf. Dependable Syst. Netw., Jun. 2015, pp. 37–44.
[21] N. Naksinehaboon, Y. Liu, C. Leangsuksun, R. Nassar, M. Paun, and S. L. Scott, ‘‘Reliability-aware approach: An incremental checkpoint/restart model in HPC environments,’’ in Proc. 8th IEEE Int. Symp. Cluster Comput. Grid (CCGRID), May 2008, pp. 783–788.
[22] S. Agarwal, R. Garg, M. S. Gupta, and J. E. Moreira, ‘‘Adaptive incremental checkpointing for massively parallel systems,’’ in Proc. 18th Annu. Int. Conf. Supercomput., 2004, pp. 277–286.
[23] H. Jin, Y. Chen, H. Zhu, and X.-H. Sun, ‘‘Optimizing HPC fault-tolerant environment: An analytical approach,’’ in Proc. 39th Int. Conf. Parallel Process., Sep. 2010, pp. 525–534.
[24] F. Petrini, K. Davis, and J. C. Sancho, ‘‘System-level fault-tolerance in large-scale parallel machines with buffered coscheduling,’’ in Proc. 18th Int. Parallel Distrib. Process. Symp., 2004, p. 209.
[25] A. Moody, G. Bronevetsky, K. Mohror, and B. R. D. Supinski, ‘‘Design, modeling, and evaluation of a scalable multi-level checkpointing system,’’ in Proc. ACM/IEEE Int. Conf. High Perform. Comput., Netw., Storage Anal. (SC), Nov. 2010, pp. 1–11.
[26] A. Kougkas, H. Devarajan, X.-H. Sun, and J. Lofstead, ‘‘Harmonia: An interference-aware dynamic I/O scheduler for shared non-volatile burst buffers,’’ in Proc. IEEE Int. Conf. Cluster Comput. (CLUSTER), Sep. 2018, pp. 290–301.
[27] M. Dorier, G. Antoniu, R. Ross, D. Kimpe, and S. Ibrahim, ‘‘CALCioM: Mitigating I/O interference in HPC systems through cross-application coordination,’’ in Proc. IEEE 28th Int. Parallel Distrib. Process. Symp., May 2014, pp. 155–164.
[28] J. Han, D. Koo, G. K. Lockwood, J. Lee, H. Eom, and S. Hwang, ‘‘Accelerating a burst buffer via user-level I/O isolation,’’ in Proc. IEEE Int. Conf. Cluster Comput. (CLUSTER), Sep. 2017, pp. 245–255.
[29] Redis in-Memory Database. Accessed: Mar. 8, 2022. [Online]. Available: https://redis.io/
[30] Block IO Controller. Accessed: Mar. 8, 2022. [Online]. Available: https:// www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt
[31] Linux Sendfile. Accessed: Mar. 8, 2022. [Online]. Available: http://man7.org/linux/man-pages/man2/sendfile.2.html
[32] Pmem-Redis. Accessed: Mar. 8, 2022. [Online]. Available: https://github. com/pmem/pmem-redis
[33] FADU Technology. Accessed: Mar. 8, 2022. [Online]. Available: http://www.fadu.io
[34] Gluster File System. Accessed: Mar. 8, 2022. [Online]. Available: https://www.gluster.org/
[35] Flexible I/O Benchmark. Accessed: Mar. 8, 2022. [Online]. Available: https://linux.die.net/man/1/fio
[36] D. Tiwari, S. Gupta, and S. S. Vazhkudai, ‘‘Lazy checkpointing: Exploiting temporal locality in failures to mitigate checkpointing overheads on extreme-scale systems,’’ in Proc. 44th Annu. IEEE/IFIP Int. Conf. Dependable Syst. Netw., Jun. 2014.
[37] Memtier Benchmark. Accessed: Mar. 8, 2022. [Online]. Available: https://github.com/RedisLabs/memtier_benchmark
[38] J. Lofstead, I. Jimenez, C. Maltzahn, Q. Koziol, J. Bent, and E. Barton, ‘‘DAOS and friends: A proposal for an exascale storage system,’’ in Proc. Int. Conf. High Perform. Comput., Netw., Storage Anal. (SC), Nov. 2016, pp. 585–596.
[39] M.-A. Vef, N. Moti, T. Süß, T. Tocci, R. Nou, A. Miranda, T. Cortes, and A. Brinkmann, ‘‘GekkoFS—A temporary distributed file system for HPC applications,’’ in Proc. IEEE Int. Conf. Cluster Comput. (CLUSTER), Sep. 2018, pp. 319–324.
[40] T. Wang, W. Yu, K. Sato, A. T. Moody, and K. Mohror, ‘‘BurstFS: A distributed burst buffer file system for scientific applications,’’ Lawrence Livermore Nat. Lab.(LLNL), Livermore, CA, USA, Tech. Rep., 2016.
[41] L. Cao, B. W. Settlemyer, and J. Bent, ‘‘To share or not to share: Comparing burst buffer architectures,’’ in Proc. 25th High Perform. Comput. Symp. (HPC). San Diego, CA, USA: Society for Computer Simulation International, 2017, pp. 1–10.
[42] H. Khetawat, C. Zimmer, F. Mueller, S. Atchley, S. S. Vazhkudai, and M. Mubarak, ‘‘Evaluating burst buffer placement in HPC systems,’’ in Proc. IEEE Int. Conf. Cluster Comput. (CLUSTER), Sep. 2019, pp. 1–11.
[43] G. Aupy, O. Beaumont, and L. Eyraud-Dubois, ‘‘Sizing and partitioning strategies for burst-buffers to reduce IO contention,’’ in Proc. IEEE Int. Parallel Distrib. Process. Symp. (IPDPS), May 2019, pp. 631–640.
[44] A. Kougkas, H. Devarajan, and X.-H. Sun, ‘‘Hermes: A heterogeneousaware multi-tiered distributed I/O buffering system,’’ in Proc. 27th Int. Symp. High-Perform. Parallel Distrib. Comput. (HPDC). New York, NY, USA: Association for Computing Machinery, 2018, pp. 219–230.
[45] B. Dong, S. Byna, K. Wu, Prabhat, H. Johansen, J. N. Johnson, and N. Keen, ‘‘Data elevator: Low-contention data movement in hierarchical storage system,’’ in Proc. IEEE 23rd Int. Conf. High Perform. Comput. (HiPC), Dec. 2016, pp. 152–161.
[46] K. Sato, N. Maruyama, K. Mohror, A. Moody, T. Gamblin, B. R. de Supinski, and S. Matsuoka, ‘‘Design and modeling of a non-blocking checkpointing system,’’ in Proc. Int. Conf. High Perform. Comput., Netw., Storage Anal., Nov. 2012, pp. 1–10.
[47] S. Thapaliya, P. Bangalore, J. Lofstead, K. Mohror, and A. Moody, ‘‘Managing I/O interference in a shared burst buffer system,’’ in Proc. 45th Int. Conf. Parallel Process. (ICPP), Aug. 2016, pp. 416–425.
[48] S. Herbein, D. H. Ahn, D. Lipari, T. R. W. Scogland, M. Stearman, M. Grondona, J. Garlick, B. Springmeyer, and M. Taufer, ‘‘Scalable I/Oaware job scheduling for burst buffer enabled HPC clusters,’’ in Proc. 25th ACM Int. Symp. High-Perform. Parallel Distrib. Comput., May 2016, pp. 69–80, doi: 10.1145/2907294.2907316.
[49] D.Koo,J.Lee,J.Liu,E.-K.Byun,J.-H.Kwak,G.K.Lockwood,S.Hwang, K. Antypas, K. Wu, and H. Eom, ‘‘An empirical study of I/O separation for burst buffers in HPC systems,’’ J. Parallel Distrib. Comput., vol. 148, pp. 96–108, Feb. 2021.
[50] A. Gainaru, G. Aupy, A. Benoit, F. Cappello, Y. Robert, and M. Snir, ‘‘Scheduling the I/O of HPC applications under congestion,’’ inProc. IEEE Int. Parallel Distrib. Process. Symp., May 2015, pp. 1013–1022.
[51] G. Zhang, L. Chiu, C. Dickey, L. Liu, P. Muench, and S. Seshadri, ‘‘AutomatedlookaheaddatamigrationinSSD-enabledmulti-tieredstorage systems,’’ in Proc. IEEE 26th Symp. Mass Storage Syst. Technol. (MSST), May 2010, pp. 1–6.
[52] X. Shi, M. Li, W. Liu, H. Jin, C. Yu, and Y. Chen, ‘‘SSDUP: A traffic-aware SSD burst buffer for HPC systems,’’ in Proc. Int. Conf. Supercomput., 2017, pp. 1–10.
Source:JIWOO BANG, ALEXANDER SIM, GLENN K. LOCKWOOD, HYEONSANG EOM, HANUL SUNG; Design and Implementation of Burst Buffer Over-Subscription Scheme for HPC Storage Systems; 7 December 2022
---【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/关注领域）